1. Field of the Invention
This invention relates to establishment of an input/output (I/O) definition in a data processing I/O system, and is more particularly related to determining if the software I/O configuration definition is in synchronization with the hardware I/O configuration definition, to providing for synchronizing the software I/O configuration definition with the hardware I/O configuration definition, and to allowing for the recovery of a hardware I/O configuration definition if an error occurs during a dynamic change from a first I/O configuration to a second I/O configuration.
2. Background Art
Data processing systems in the field of art of the present invention typically comprise a central processor complex attached to one or more control units and their associated I/O devices in an I/O subsystem (or with other processor complexes), and central storage; and the CPU further comprises an Arithmetic Logical Unit (ALU), registers, high speed buffers, and the Processor Controller. Such systems are typically managed by a control program such as IBM's MVS/ESA.
Since such a system has a high degree of modularity, it is a routine event to add, delete, or exchange control units, I/O devices, or change channel path configurations, in the system. A particular I/O configuration must be defined both to the system's channel subsystem and operating system software, and a change to an I/O configuration occasioned by the addition, deletion, or exchange of an I/O element (channel, control unit, or I/O divice) must be reflected in a change to the hardware and software definition.
In the past it has been a matter of some difficulty to change a system's I/O configuration without disrupting active processing or the system. A normal course of events would be to establish a new set of definitions, stop processing of work on the system, add, delete, or change the I/O elements by performing the physical connection, disconnection, or reconnection, then power-up and initialize the hardware and IPL the operating system to reestablish the correct hardware and software definitions, and again start the processing of work.
This was recognized to be unacceptably disruptive and expensive, requiring as it does that the system be idle for a possibly long time period while the reconfiguration is performed. Therefore, schemes were devised to reduce the impact on system processing: one such scheme involved "over-defining" an I/O configuration--i.e., setting up definitions (control blocks) for nonexistent (at present) I/O elements, which could then be utilized later when new I/O elements are added. However this scheme has its limitations: the number of reserved definitions is a largely matter of intelligent guess work; space is wasted by the reservation of the unused control blocks; the scheme allows for the addition, not the deletion of I/O elements; and certain types of changes (such as the incorrect specification of device's "type") still required a system reinitialization.
Other schemes provided for the dynamic addition of a device definition without pre-reservation of control blocks, but did not deal with I/O element deletion since deletion poses the additional problem of the treatment of ongoing system work making use of the I/O element to be deleted--again, the traditional method of dealing with this situation was to "quiesce" the system (completing ongoing work without starting new work) so that the I/O element could be disconnected, and I/O element definition deleted, without adversely affecting ongoing processing. Still other schemes dealt with changing the characteristics of existing I/O element definitions again leaving unresolved the matter of whether or not active work must stop, and how to deal with device additions, or deletions.